Le Paradoxe des performances affirme qu'un noyau mathématiquement parfait, comme $out = x + y$, peut en réalité fonctionner plus lentement qu'une boucle CPU si les coûts fixes du matériel GPU ne sont pas amortis. Cela se manifeste souvent sous forme de Frais de lancement.

1. L'erreur de la « correction »

La correction fonctionnelle n'est pas un indicateur d'efficacité. Même si votre code Triton répartit correctement le travail sur des milliers de threads, si la quantité totale de travail (N) est faible, la GPU reste sous-utilisée. Le matériel passe plus de temps dans les transitions d'état que dans des calculs réels.

2. Le piège de mesure en Python

Mesurer le code GPU depuis Python en utilisant time.time() est dangereux. Les appels GPU sont asynchrones; Python ne fait que mettre en file d'attente la commande et continue. Sans torch.cuda.synchronize(), vous mesurez le temps d'attente. Avec la synchronisation, vous mesurez la latence hôte-vers-dispositif, qui est souvent 10 fois plus longue que l'exécution du noyau lui-même.

3. Latence vs. Débit

Pour surmonter ce paradoxe, il faut fournir suffisamment de travail pour « cacher » la latence de lancement. C'est la transition d'un régime limité par la latence (limité par le bus CPU-GPU) vers un régime limité par le débit (limité par la mémoire ou le calcul GPU).